Model-based Management of Web Service Compositions in Service-Oriented Architectures

Web service compositions (WSC), as part of a service-oriented architecture (SOA), have to be managed to ensure compliance with guaranteed service levels. In this context, a high degree of automation is desired, which can be achieved by applying autonomic computing concepts. This paper particularly focuses the autonomic management of semi-dynamic compositions. Here, for each included service several variants are available that differ with regard to the service level they offer. Given this scenario, we first show how to instrument WSC in order to allow a controlling of the service level through switching the employed service variant. Second, we show how the desired self-manageability can be designed and implemented by means of a WSC manageability infrastructure. The presented approach is based on widely accepted methodologies and standards from the area of application and web service management, in particular the WBEM standards. 1 0B0B0BIntroduction Today, companies require IT support that is tightly aligned with their business processes and highly adaptive in case of changes. These requirements can be met by employing a Service-Oriented Architecture (SOA) [ XXXvdAtHW03 XXX]. In SOA, functionality required for executing business processes is provided by atomic web services (WS) or by web service compositions (WSC). A WSC is designed in a strictly process-oriented way and implements fully automated parts of business processes or even long-running workflows [ XXXLRS02 XXX]. Each service – composite or atomic is characterized by the fact that it is operated by a service provider and the terms of use are contractually fixed by means of Service Level Agreements (SLA). Such an SLA may for instance constitute that a WSC has to adhere to a certain response time constraint. While providing the service the provider has to assure the compliance with the corresponding SLA. To this end, the provider has to be able to monitor the actual service levels and be able to react to detected SLA violations as part of his service level management. These management functions should be automated as far as possible [ XXXSMS+02 XXX]. Only in this way the vision of an “on-demand” provisioning of the offered (composite) web services can be reached [ XXXDDK+04 XXX]. An automated service level management for WSC can – at least partly be achieved by applying autonomic computing concepts, as for instance presented in [ XXXIBM04 XXX]. The managed resources in this context are the WSC. These resources should be equipped with self-management capabilities, which are realized through autonomic managers. More precisely, the autonomic managers implement so-called intelligent control loops, which generally comprise a monitor, analyze, plan and execute function. To implement these functions, the managed resources, in our case the WSC, have to provide an adequate manageability interface allowing for both the monitoring and controlling of the resources. This is enabled though sensors and effectors added to the managed resource, which is also referred to as “instrumentation”. As part of our preliminary work, we already presented the design and implementation of a manageability infrastructure for WSC based on the Web-based Enterprise Management (WBEM)FFF 1 FFF standards [ XXXMMRA07 XXX, XXXRat07 XXX]. In this way, a standardized manageability interface is offered that allows a fine-grained monitoring of WSC as part of an SLAdriven management. The required monitoring instrumentation is based on sensors added to the WSC. This paper now focuses on the controlling instrumentation of WSC and the enhancement of a WSC manageability infrastructure by incorporating autonomic management concepts, in the following referred to as self-manageability. In this context, we regard the autonomic managers themselves to be part of the manageability infrastructure. We furthermore assume the WSC to be of semi-dynamic nature [ XXXZK06 XXX]. This means that the composition logic itself is static but several variants of the included services are available that differ with regard to the service levels they offer [ XXXTP05XXX]. The concretely employed service variants may be selected dynamically during or prior to the execution. The actual contribution of this paper is twofold. First, we present and discuss different approaches to a controlling instrumentation (i.e. effectors) of WSC. To ensure universal applicability, we focus on BPEL-based WSC. Additionally, the proposed solutions do not rely on any vendor-specific extensions of the employed BPEL engines, i.e. they are platform-independent. To minimize the effort for instrumenting the WSC we show how generative techniques could be used for an automation of this process. Second, we show how self-manageability can be designed and implemented by means of a tailored WSC manageability infrastructure. Here, we leverage the WBEM standards to obtain a flexible solution that may easily be integrated into existing management environments. The management requirements and proposed solutions are demonstrated by means of a concrete scenario taken from the field of higher education. Before introducing this scenario, we first provide an overview of the relevant related work. 1 http://www.dmtf.org/standards/wbem/ 2 1B1B1BRelated Work The controlling and eventually self-management capabilities for WSC may be used within an SLA management infrastructure. In literature, two major solutions for a SLAbased management of WS and WSC have been presented, which rely on an instrumentation of the managed resources and a manageability infrastructure. In [ XXXDDK+04 XXX], a solution for an automated SLA-driven management on basis of Web Service Level Agreements (WSLA) is presented. However, this solution mainly focuses on monitoring SLA compliance of atomic WS and does neither adequately support the monitoring nor the controlling of WSC. In [ XXXDK03 XXX], the approach is extended by a WBEM-based monitoring infrastructure. WSC monitoring is now partially supported, but management capabilities are not covered either. In [XXXSMS+02 XXX], a competing solution is presented which supports an automated SLA compliance monitoring of atomic WS and WSC. However, the solution represents a very proprietary approach as the manageability interface is not built on standards. Furthermore, the solution is also limited to monitoring capabilities. Each of the previously introduced approaches supports the flexible negotiation of discrete or continuous service level parameters. This results in a vast variety of offered service variants and implies enormous challenges for the service provider concerning the provisioning and management of the eventually provided service variants. In [ XXXTP05XXX], a more pragmatic approach is presented, based on a language for defining web service offerings [ XXXTPP03XXX]. This allows the specification of different discrete variants of one WS in terms of service offerings. In contrast to WSLAs, the customer cannot freely negotiate all kinds of service level parameters, but may rather choose the predefined service variant most appropriate for him. A corresponding management infrastructure is presented in [ XXXTMPE04XXX]. The scope of this infrastructure is limited to the monitoring of atomic WS. However, the idea of offering discrete service variants of one service serves perfectly well as a basis for (autonomically) controlling and managing the service level of a WSC. On the one hand, this is because algorithms and protocols used by the WSC provider to determine and negotiate the optimal service allocation for a WSC are much simpler. On the other hand, support for dynamic negotiation and provisioning for the offered services is not required. Given a discrete set of service variations for a service included in a WSC, the WSC provider still requires a clear understanding of the dependencies between the service levels offered by the WS and the resulting service level of the WSC. More precisely, detailed knowledge of how the service level parameters are composed according to the (functional) composition pattern is needed. This aspect is particularly addressed in [ XXXJRGM05XXX]. In [ XXXZLD+05 XXX], a completive approach is presented, which also addresses the optimization of the service selection for dynamic WSC. However, this infrastructure builds on a proprietary workflow engine. The issue of an interoperable and standardbased instrumentation and manageability interface is not addressed. Furthermore, the automated adaptation of the WSC is triggered by changing service offerings or user preferences. An adaptation on basis of self-manageability model as part of an intelligent control loop is not considered. In [ XXXKap05XXX], an interesting approach to the specification of such self-manageability policies is presented. The authors propose to create health models based on finite state machines to model the autonomic behaviour as a starting point for the manageability design. Unfortunately, it is not shown how these models are actually implemented by means of a manageability infrastructure. With regard to the controlling instrumentation, the concept of parameterized web services flows described in [ XXXKLB05 XXX] represents a very promising approach. This allows the fully dynamic selection of included services at runtime by adding and evaluating corresponding mapping rules within the WSC. Unfortunately, these selection rules may not be changed at runtime. They are rather set at design time. Our solution can therefore be regarded as complementary to the aforementioned approach. 3 2B2B2BMotivating Example and Self-Manageabililty Requirements In this section, we introduce a simplified real-life scenario motivating the application of a semi-dynamic service selection. On the basis of this scenario, we present major requirements for a corresponding manageability infrastructure and the controlling WSC instrumentation. Furthermore, assumptions and limitations implied by the scenario are pointed out. The scenario is situated in the field of higher education. More precisely, we are working on a project that is concerned with the development of a SOA which is supposed to support study and administrative processes [ XXXFJL+06 XXX]. In the following, we focus on a service-oriented IT support for the process of managing examinations. An examination management system (EMS) is offered by the central administration. The functionality (e.g., registering for exams or capturing exam results) of the EMS is exposed through atomic WS, also provided by the central examination. The examination management process is supported by process-oriented, long-running WSC. The departments account for developing, adapting and operating their specific WSC, as they are specific to the study courses offered by them. The WSC provider solely accounts for ensuring the guaranteed service levels. The service level of a WSC thereby relies on the workload, the service levels of the composed WS and the performance of the execution environment, in particular the employed composition engine. The WSC has to be adjusted to a changing workload. The WS provider – the central administration – offers several variants of the same service with regard to the provided service level. Depending on the given workload, the WSC provider – the university departments – may choose the most appropriate variant of the WS. The long-running WSC supporting the process of managing examinations, is illustrated in Figure 1. This WSC requires the RegistrationService and the ExaminationResultService provided by the EMS and an additional TaskManagementService supporting user interactions. As the different operations offered by the ExaminationMgmtComposition are used via a web-based portal, the response time (RT) of each operation, particularly the registration, must not exceed 2 sec. All included WS are offered by the central administration in two variants, which represents a simplified setting. All variants guarantee a RT of less than 1 sec, but with different workload limits, expressed in requests per minute (req/min). Variant B handles 500 req/min and A tolerates up to 1000 req/min. The offered WS variants are provided through different service endpoints. Figure 1. ExamMgmtService Composition Definition We focus on the looped activity for processing registrations. This activity is started after the examination terms have been assessed. Registrations submitted by students are first received using the WSC’s operation register, then validated and stored by invoking the respective operations offered by the RegistrationService. Depending on the validation result, a confirmation or denial message is returned to the caller, again through the operation register. As a result, the response time of this operation is mainly determined by this sub-process. Using QoS composition patterns as presented in [ XXXJRGM05 XXX], the following response time for the whole operation can be estimated.: RT WSC.register = RTRegistrationService.check +P(prereq == true) RTRestrationService.register For the sake of simplification, we neglect the constant time factor required by the BPEL engine itself. Given the available offerings, in the worst case (P = 1) this would lead to an aggregated RT of less than 2 sec, which in any case complies with the given requirement. As for the workload (WL), we need to know how it is distributed to the included service operations: WLRegistrationService.check = WL WSC.register (1) WLRestrationService.register = P(prereq == true) WL WSC.register (2) In this scenario, a feasible self-manageability policy would be to switch to Variant A of the RegistrationService as soon as an average workload greater than 500 req/min has been detected during the last hour. Otherwise, Variant B is used. With regard to the instrumentation this implies that on the one hand it is necessary to monitor the workload. On the other hand, a mechanism for changing the actually employed service variant at runtime is required, even for already running WSC instances. In our case, for each examination one long-running instance of the WSC is created. Note that this is a very simple scenario intended to demonstrate self-manageability requirements. Within the service selection, we particularly neglect the costs of each service variant and present a very limited, static service offering. A larger variety of dynamically changing offerings as well as the inclusion of cost would result in a complex optimization problem, as presented in [ XXXGJ05 XXX]. Solving this problem would then be part of the intelligent control loop (plan function) implemented by an autonomic manager. However, this aspect is part of our future work. 4 3B3B3BControlling Instrumentation Design To provide self-manageability a controlling instrumentation of the WSC is required in the first place. More precisely, extensions of the WSC implementation are needed that allow a dynamic reconfiguration of the actually employed service variants at runtime. We already pointed out two major requirements this instrumentation must meet: Support for reconfiguration of running WSC instances Applicability for all kinds of BPEL engines Taking these requirements into account we identified two feasible approaches. The first one represents the employment of proxy WS. In this case, a proxy is generated for each included service which offers the same WS interface as the original WS. The WSC includes only the proxy WS. When calling it, the proxy determines the service endpoint of the actual WS variant, invokes it and returns the result to the WSC. The endpoint may either be retrieved from a configuration services or from a local properties file or database. In the latter case, the proxy has to offer an interface for updating this information. This approach has some advantages. First, the proxy can easily be generated as interfaces are identical to the original WSDL and internal logic is straight forward. Second, configuration changes directly affect all running instances as well as instances that will be newly created without having to explicitly change/reconfigure them. As a major drawback, this solution in either case requires at least one additional call of the proxy. If the configuration service is asked for the endpoint, another additional call is needed. This is why – after implementing this approach – we looked for a less resource demanding alternative. The constraint of being platform-independent led us to the employment of dynamic endpoint references, as proposed by the BPEL 1.1 standard [ XXXACD+03 XXX]. This mechanism allows a dynamic reconfiguration of the service endpoint for a given partnerLink at runtime by using a standard activity. However, the WSC has to be provided with the information on which endpoint it has to use for a particular partnerLink. Moreover, it has to be possible to change this configuration information within a running WSC instance. This calls for extensions of the BPEL-based composition definition as well as the provided WSC interface in terms of the corresponding WSDL. Figure 2 shows an instrumentation pattern for extending arbitrary BPEL definitions with controlling capabilities. Figure 2. Controlling Instrumentation BPEL Alternative An additional invocation activity, that is inserted after the first receive activity, retrieves the service variant configuration from a configuration service. This information is stored in a newly added BPEL variable. An AND split divides the execution path into two branches executed in parallel. The first branch holds the original composition definition as an embedded sub process. Additionally, an that initializes the dynamic partnerLinks has to be added before each activity. The second branch enables the asynchronous receiving of configuration updates. Once a new configuration has been received, the local configuration variable is updated. To continuously provide the possibility of reconfiguration, these activities are placed within an endless loop. The composition terminates as soon as the original composition situated in the first branch terminates, as these branches are joined by means of an OR join. Unfortunately, the combination of AND split and OR join is not explicitly supported by BPEL yet. Thus, in the BPEL-based implementation, a standard activity is used, which corresponds to an AND split with an AND join. To terminate the second branch, a custom fault event is thrown after the original composition has completed. The fault event is caught in an empty exception handler added to the outmost . In this way, the whole composition is terminated. It is obvious that the BPEL-based instrumentation is a more efficient approach than the proxy alternative in terms of management-related overhead at runtime. Additional service invocation activities are only required once at the beginning and as soon as a reconfiguration is actually desired by the manager. Nevertheless, at design time this approach causes a higher complexity. This problem is addressed in the following section. 5 4B4B4BAutomated Generation of a Bpel-Based Controlling Instrumentation In this section we present an XSLT for the automated transformation of a given BPEL composition definition into an instrumented composition definition. The following code snippet displays the structure of a typical BPEL definition. [...] [...] [...] [...]